chdkfandomcom-20200222-history
Cameras' imaging capabilities
A collection of movie mode (and other) capabilities. The purpose of this table is to give an overview of all CHDK-capable cameras. It's concentrating on image capture capabilities, not on optical or usability ones. The sensor's raw resolution and physical dimensions may indicate that *camera models, whose sensors share the same size, technology and raw resolution may have been built with the same sensor. A certain sensor model always has the same capabilities, even if the camera doesn't use them (this applies to movie modes - frame rate and/or resolution). Columns P-ID: P(roduct) ID of the model, hexadecimal only Model: Camera's market name(s), link to its wikia page DIGIC: DIGIC processor generation OS: Operating system on camera (Vx - VxWorks, Dry - DryOS), including revision Sensor: Effective pixel count (total pixel count), size, based on the official specification RAW res.: Sensor raw resolution, as found in firmware S. type (sensor type): CCD / CMOS, make (Sony, Pana''sonic, etc.) '''Mvi. fmt.': Movie file format (AVI - video always MJPEG, MOV - video always h.264) Max. movie res.: Highest movie resolution @ fps, source dimensions, source pixel format Other m. res.: Another (more or less interesting) supported movie mode Enc.: Movie video frame encoder routine (programming info for future use, has to be rev. engineered) Notes: *rc: officially remote controllable via PC (includes liveview over ptp) *raw: official raw support (in still image mode) Table Miscellaneous information DIGIC II doesn't seem to be able to provide sensor liveview with more than one resolution at the same time. Later DIGIC (III or later) can do that. On DIGIC II cameras in hi-res movie mode, the framebuffers use a vertical resolution that is provided by the sensor. On later DIGIC, the framebuffers already contain a pre-resized image. Earlier CCD models with a 60fps low-res movie mode have a short time limit in that mode. Reason unknown (marketing?). Exceptions: TX-1 (this one seems to have greater processing power anyway), S3IS (according to official specs), S5IS (according to official specs). Cameras with remote liveview (rc indication in notes) use the movie video encoder routine (mjpeg) for video compression. One of the latest remote controllable cameras is the G10. It's pretty special: DIGIC 4, uses h.264 for video encoding in movies but also has the mjpeg encoder routine for remote liveview. Programming information Video frame encoder routine parameters vx1) Earlier VxWorks / DIGIC II, MJPEG A420, 100b This may not apply to models that have a 1024x768 mode... The target frame resolution is decided in the encoder routine. The source is always a 720px wide framebuffer, the source frame is always "top left". The source pixel format is always Y411. Parameters of sub_FFC80EE4 (values in 320x240 movie mode, while recording), might contain mistakes r0: address of the current framebuffer r1: 360, src frame width in pixels r2: 191, src frame height in pixels r3: destination address (compressed frame to be placed at, the co-processor can only write to 32bit aligned addresses!), useful mjpeg data begins at start+0x18 or start+0x1a with the current canon code (alignment is 2 bytes when recording a movie) //passed on caller's stack: sp+0x00: 0x20000, probably compressed framesize limit sp+0x04: 0 ... offset? sp+0x08: 0 ... offset? sp+0x0c: pointer to avi vidframe size (on caller's stack), to be filled by the encoder routine sp+0x10: 0x720c8 = 0xffc7bb54, looks like a pair of quantization tables sp+0x14: 0x720d4, compression quality (0..99?) sp+0x18: caller's sp+0x1c, gets set to 0 when compression was ok dry1) Earlier DryOS / DIGIC III, MJPEG SX100, A470 The target frame resolution is also decided in the encoder routine. The source framebuffer's dimensions vary depending on the movie mode. The routine can handle at least 2 pixel formats: Y411, UYVY There are signs of a third possible format which uses 32 bits per pixel (RGBA?). In case of the SX100, this encoder routine is also called from the "remote EVF" routine, so the remote live view also uses MJPEG compression. Parameters of sub_FFCD75D4 (SX100IS, 100c) r0: address of the current framebuffer r1: src frame width in pixels r2: src frame height in pixels r3: destination address (alignment: 2 bytes) //passed on caller's stack: sp+0x00: probably compressed framesize limit in bytes sp+0x04: 0 ... offset? sp+0x08: 0 ... offset? sp+0x0c: pointer to avi vidframe size (on caller's stack), to be filled by the encoder routine sp+0x10: quantization table address sp+0x14: compression quality (0..99?) sp+0x18: src pixel format (0=Y411, 1=UYVY) sp+0x1c: src framebuffer width in pixels sp+0x20: pointer to "compression OK" flag, gets set to 0 when compression was ok Table shamelessly stolen from P-ID (Table). Category:Development